Skip to content

Catch the README up with the Vision Pro app - #57

Merged
temoki merged 3 commits into
mainfrom
docs/readme-viewer
Aug 23, 2026
Merged

Catch the README up with the Vision Pro app#57
temoki merged 3 commits into
mainfrom
docs/readme-viewer

Conversation

@temoki

@temoki temoki commented Aug 23, 2026

Copy link
Copy Markdown
Owner

The README described the app #11 shipped, not the one #53 replaced it with: the same three panes in a window on Vision Pro. A reader deciding whether a visionOS build was worth having got the answer that argued against it. It also showed one picture — the Mac editor — for a page that now claims a viewer exists.

What changed

The Vision Pro app is described as what it is. A feature bullet of its own, and Requirements now says the three-pane editor on iPad and Mac, and on Vision Pro a viewer for what they made, with no editing in it at all.

The tree had not heard of three directories. App/Views/Viewer/, TortoiseBlocksUITests/ and Tools/ are in it now — and fastlane/ is no longer called the only Ruby in the repository, which stopped being true when the capture rigs arrived.

Releasing gained what a second listing costs. Which directory each platform reads (metadata for iOS and macOS, metadata-visionos for visionOS, because the description that sells the editor would be describing a product that does not exist there), why the app-level fields are checked byte-identical, and where the captures come from.

And the pictures. docs/Viewer.png is new — the drawing on the table with the blocks and the Swift either side of it. docs/Screenshot.png is refreshed from the current Mac tree capture.

The one thing that is not documentation

Tools/screenshots.rb now derives both README images, rather than them being exported by hand. What a reshoot silently leaves behind is the picture nobody has open while shooting — site/shots was forgotten twice before it was folded into this script, and a README image is further out of sight than the website. Same recipe as the site copies, 256 colours, which is also what keeps the run reproducible: a second pass over unchanged captures rewrites nothing, checked before committing. The Mac image drops from 679KB to 141KB on the way through.

The Mac one is shot 4, the tree, on purpose: it is the only capture in the set that shows a block calling itself, which is what the README's longest bullet is about. Both images were composed by hand before the rigs existed, so this refreshes them rather than replacing them — the window sits a little differently and the workspace is scrolled to a different row, which is what a re-shoot of the same scene looks like.

Not in this PR

The site/hold-at-1.0.0 branch, which records in the release skill that the live site is being held at 1.0.0 until iOS 1.0.0 clears review. Separate concern, separate branch.

temoki added 3 commits August 23, 2026 15:19
It said the same three panes in a window, which is what #11 shipped and
what #53 replaced: on Vision Pro there is no editing at all, the drawing
lies on a real table, and the blocks and the Swift stand in windows either
side of it rather than taking turns in one pane. A reader deciding whether
a visionOS build is worth having got the answer that argued against it.

The tree had not heard of the viewer, the capture rigs or the UI test
target that drives them, and it still called fastlane/ the only Ruby in
the repository — Tools/ is four Ruby scripts now. Releasing gains the two
things a second listing costs: which directory each platform reads, and
why the app-level fields have to match byte for byte.
The page now says the app there is a viewer with no editing in it, and then
shows one picture: the Mac editor. The claim that is hardest to picture was
the one with nothing to look at.

The capture is derived by Tools/screenshots.rb rather than exported by hand,
because the thing a reshoot leaves behind is the picture nobody has open while
shooting — the same reason site/shots is derived, and it was forgotten twice
before that was. Same recipe as the site copies, 256 colours at 1600x900,
which is also what makes a second run reproduce the file instead of rewriting
it: checked, and the run comes back clean.

docs/Screenshot.png stays hand-made and out of the table. It is a composition
of its own — a Mac window over a desktop, palette open, the tree half-drawn —
and no App Store capture matches it, so deriving it would swap the picture
rather than refresh it.
Leaving it out was argued from one comparison against the wrong capture —
the star — and read as "no App Store capture matches this". The Mac set has
shot 4, the same scene: tree.tortoise, palette open, 🌳 calling itself, the
fractal beside it. The committed picture predates the rigs and was composed
by hand, so this refreshes it rather than replacing it; the window sits a
little differently and the workspace is scrolled to a different row, which is
what a re-shoot of the same thing looks like.

Both README images now come out of the same table as site/shots, so a reshoot
cannot leave either behind. The Mac one is the tree on purpose: it is the only
capture that shows a block calling itself, which is what the README's longest
bullet is about. 679KB to 141KB on the way through, and a second run over
unchanged captures still rewrites nothing.
@temoki
temoki merged commit 8499a04 into main Aug 23, 2026
7 checks passed
@temoki
temoki deleted the docs/readme-viewer branch August 23, 2026 06:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant